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1 Field Of The Invention 

2 The invention relates generally to the field of digital computer systems, and more particularly 

3 to systems and methods for scheduling of processes or threads for execution by a computer. The 

4 invention particularly provides a system and method for efficiently scheduling of processes or 

5 threads comprising a parallel job for execution on a computer having a plurality of processors, such 

6 as a computer constructed according to a symmetric multi-processor architecture, a cluster of such 

7 computers, or the like. 

3 Background Of The Invention 

h£ Computers typically execute programs in one or more processes or threads (generally 

i !ft "processes") on one or more processors. If a program comprises a number of cooperating processes 

tB which can be processed in parallel on a plurality of processors, problems arise in connection with 

O scheduling execution of the processes so that the programs can be executed in an efficient manner. 

jQ Typically, operating systems have scheduled processes without regard to whether they comprise part 

.ESS. 

y of a parallel program, which can lead to severe inefficiencies in execution. For example, if one 

@ process in a parallel program is waiting for data that is to be provided by another process in the 

16 parallel program, or perhaps from another program, if the operating system enables the waiting 

1 7 process to be executed before the process which is to supply the data has provided the data, the time 

1 8 during which the waiting process is executed will be wasted. The problem is exacerbated when the 

1 9 computer is processing several such parallel programs contemporaneously, and the total number of 

20 processes of all parallel programs is greater than the number of processors in the computer available 

21 for executing those processes. 

22 Several methodologies have been developed for scheduling execution of processes 

23 comprising one or more parallel programs. In one methodology, referred to as "batch-queuing," the 

24 computer executes processes of only one parallel program at a time, and executes those processes 
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1 until all are completed. However, batch-queuing generally precludes sharing of the computer in an 

2 interactive manner. 

3 In another methodology, referred to as "gang scheduling," the computer also executes 

4 processes of only one parallel program at a time, but allows for interactivity. In a computer which 

5 implements the gang scheduling methodology, a master entity, forming, for example, part of the 

6 operating system, periodically determines which parallel program to schedule at any point in time. 

7 Preferably, the master entity will make such determinations at frequent, regular intervals. At the 

8 beginning of each interval, the master entity selects which parallel program is to be processed during 

9 the interval, and allow all of the processes of only the selected program to be executed during the 
T§ interval. At the end of the interval, the master entity will stop execution of that program and select 
H another program to be executed. This methodology allows for interactivity with the various 
W programs being executed, but the master entity adds a not-inconsiderable amount of processing 

» if overhead. The overhead can be reduced by making the intervals longer. However, if the intervals 

ft are made longer, the interactivity response time can be relatively poor. In addition, with this 

f! methodology it is not possible to process two parallel programs that communicate with each other 

y> since they will never be scheduled for execution at the same time. 

f| In a third methodology, referred to as "co-scheduling," each process, while it is being 

1 8 executed, determines for itself whether it is to be scheduled for execution, or to de-schedule itself. 

19 The processes can make the determination based on a number of factors, such as, for example, its 

20 communication patterns, responsiveness of other processes to requests, whether it is waiting for 

21 information from another process, and the like. For example, if aprocess determines that it has been 
: 22 waiting too long for information from another process, it (that is, the waiting process) can de- 

23 schedule itself, so that it will not be executed. This allows execution of other processes, which are 

24 not similarly waiting for information and which therefore can make progress in their processing 

25 operations. Since each process determines whether it is to be scheduled, no master entity is required 

26 to make such scheduling decisions. In addition, since a computer can be executing the processes 
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1 comprising multiple programs, the methodology allows for a high degree of interactivity and 

2 execution of multiple parallel programs that communicate with each other. 

3 Summary Of The Invention 

4 The invention provides a new and improved system and method for efficiently controlling 

5 scheduling of execution of processes or threads comprising one or more parallel programs in a 

6 computer having a plurality of processors, such as a computer constructed according to a symmetric 

7 multi-processor architecture or a cluster of such computers. 

In brief summary, A system is described for controlling co-scheduling of processes in a 

, S computer comprising at least one process and a spin daemon. Each process, when it is waiting for 

H a flag to change condition, can transmit a flag monitor request to the spin daemon and enable itself 

\ fl to be de-scheduled. The spin daemon, after receiving a flag monitor request, monitors the flag and, 

12 after the flag changes condition, enables the process to be re-scheduled for execution by the 

S§ computer. 

S Since the spin daemon can monitor flags for a number of processes, the ones of the processes 

@ that are waiting will not need to be executed, allowing other processes that are not just waiting to 

16 be processed more often. 

1 7 Brief Description Of The Drawings 

18 This invention is pointed out with particularity in the appended claims. The above and 
.19 further advantages of this invention may be better understood by referring to the following 
20 description taken in conjunction with the accompanying drawings, in which: 
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FIG. 1 schematically depicts a computer system including an arrangement for efficiently 
controlling scheduling of processes or threads comprising one or more parallel programs in a 
compute having a plurality of processors, constructed in accordance with the invention; and 

FIG. 2 is a flowchart depicting operations performed by the scheduling control arrangement 
in the computer depicted in FIG. 1 . 

Detailed Description of an Illustrative Embodiment 

FIG. 1 schematically depicts a computer 10 including an arrangement for efficiently 
controlling scheduling of processes or threads comprising one or more parallel programs in a 
compute having a plurality of processors, constructed in accordance with the invention. Generally, 
the computer 10 includes hardware resources which are preferably constructed along the lines of a 
symmetric multi-processor architecture, in which a plurality of processors (not separately shown) 
share common memory resources (also not separately shown), or a cluster of such computers. In the 
computer 10 depicted in FIG. 1, a plurality of programs 11(1) through 11(N) (generally identified 
by reference numeral 1 l(n)), each comprising one or more processes 12(1)(1) through 12(N)(M) 
(generally identified by reference numeral 12(n)(m)). The processes 12(n)(m) share a common 
memory 13, with each process being allocated a portion 13(n)(m) of the memory 13. The total 
number of processes which the computer system 10 will execute may be greater than the total 
number of processors in the computer system 1 0, and, if so, the computer's operating system 14 will 
enable the processes to be executed in a series of time intervals or slots, with the particular ones of 
the processes that be executed during a time slot being listed on a task list 15. When a process 
12(n)(m) is listed on the task list, it can be "scheduled" for execution, on the other hand, when a 
process 12(n)(m) is not listed on the task it has been "de-scheduled" and the operating system 14 will 
not enable it to be executed until it is again scheduled. At the end of each time slot, the operating 
system selects the processes that are to be executed from among those that are listed on the task list 
15. 
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1 As noted above, each process 12(n)(m) is allocated a portion 13(n)(m) of the common 

2 memory 13, which it will normally use in its processing operations. Each process 12(n)(m) can, 

3 however, communicate with another process 12(n ! )(m f ) (where one or both of V" and "m"' will 

4 differ from "n" and "m") by sending messages thereto. The messages effectively result in the storing 

5 ofinformation in the memory portion 13(riXm') of memory 13 allocated to that process I2(v!)(m!). 

6 A process may communicate with another process for several reasons. For example, a process may 

7 communicate with another process to request that the other process provide it with information 

8 which it may need in its processing operations. In that situation, after the process receiving the 

9 processing request, it (that is, the process which receives the processing request) will at some point 
14 perform the processing operations to generate the requested information. After the information has 
ft been generated, the process which generated the information can provide the information to the 
Q process that generated the request. In both cases, the process loads information (either the 
lj| information generation request or the generated information) into the memory portion of the process 
iff which is to receive the information. Thus, if one process 12(n)(m) is requesting information from 
K5 another process 12(n f Xm'), it (that is, process 12(n)(m)) will load the request into the memory 
1|§ portion 13^)^) associated with the other process. Similarly, if one process 12(n)(m) is loading 
13- information requested by another process 12(n r )(m f ), it (that is, process 12(n)(m) will load the 
t8 requested information into the memory portion 13(n f )(m') associated with the other process. In 

1 9 addition, if the information is in response to a request, the process 1 2(n)(m) will set a flag 1 6(n T )(m 1 ) 

20 in the memory portion 1 3(ri)(m') to indicate that it has stored the information in the memory portion 

21 1 3(n')(m'). Thereafter, the process 12(n ? )(m f ) can make use of the information that has been loaded 

22 into its memory portion B^Xm') by process 12(n)(m) and, at some point, reset the flag ^(n'Xm 1 ). 

23 If the process 12(n ! )(m T ) is waiting for information from the process 12(n)(m), which may 
,24 occur after it issues a processing request to the process 12(n)(m), it (that is, process 12(n f )(m')) will 

25 perform a "spin-wait" loop in which it periodically tests the flag 16(n')(m f ). While performing the 

26 spin- wait loop, the process 1 2(n')(m f ) will need to delay performing other processing operations until 

27 the process 12(n)(m) has loaded the information in its memory portion 13(n ! Xiri) and set the flag 
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1 1 6(p!)(m'). It will be appreciated that, while the process 1 2(n t )(m*) is in the spin-wait loop, it is not 

2 performing processing operations, and so time that it is performing the spin- wait loop will essentially 

3 be wasted. The process 1 2(n)(m) may be delayed in providing the information required by process 

4 12(ri)(m') for a number of reasons, including, for example, that it is not being executed by the 

5 computer 1 0 in the current time slot, that it is not scheduled for execution, that the process 1 2(n)(m) 

6 needs a relatively long time to generate the information to be provided, and other reasons which will 

7 be apparent to those skilled in the art. To reduce the amount of processing time that may be wasted 

8 by the process 12(n r )(m') executing the spin loop, the computer 10 also includes a spin daemon 17 

9 which, after receiving a flag monitor request therefor from the process 12(n ! )(m'), can monitor the 
14i condition of the flag 16(n')(m') for the process 12(n')(m'). The process 12(n')(m f ), after issuing the 
f% flag monitor request to the spin daemon 17, can thereafter de-schedule itself, by removing its 

* £3 identification from the task list 15, and provide a notification to the operating system 14 giving up 

13 any remaining portion of its current time slot. After the process 12(n')(m') gives up any remaining 

fil portion of its time slot, the operating system 1 4 can initiate execution of another process 1 2(n")(m") 

15 (where one or both of n" and m" will differ from n' and m ! ) during that time. In addition, since the 

IS process 1 2(n')(m ! ) has de-scheduled itself, the operating system 1 4 will not again enable the process 

pt 1 2(n')(m') to thereafter be executed. 

fl After receiving the flag monitor request from the process 1 2(n f )(m ! ), the spin daemon 1 7 will 

1 9 add the flag monitor request to a spin list 1 8 which it maintains. The spin list 1 8 identifies the flags 

20 in memory whose condition it is to monitor. Accordingly, after the spin daemon 17 adds the flag 

21 monitor request to the spin list 18, it will thereafter monitor the condition of the flag 16(n')(m f ). 

22 When the process 1 2(n)(m) sets the flag, indicating that it has provided the information required by 

23 process 12(n ! )(m r ), the spin daemon 17 will enable the process 12(n f )(m f ) to, in turn, enable the 
,24 operating system 14 to re-schedule the process 12(n r )(m') by re-loading its identification on the 

25 operating system task list 16. The operating system 14 can thereafter enable the process 12(n')(m') 

26 to be executed in the same manner as before it had de-scheduled itself Since by the time the process 

27 12(n , )(m t ) is re-scheduled, the process 12(n)(m) will have provided the information required by 
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1 process ^(n'Xm'), it (the process 12(n , )(m ! )) will be able to make progress in its processing 

2 operations, using the information provided by the process 12(n)(m), and will not need to return to 

3 spin-wait loop, 

4 It will be appreciated that the spin daemon 1 7 may be implemented in the form of a process 

5 or thread (generally, "process"), and will essentially be performing a spin-wait operation in 

6 connection with the flag 1 6(n')(m') associated with the process 12(n , )(m f ) that issued the flag monitor 

7 request. However, the spin daemon 1 7 can perform these operations in connection with flag monitor 

8 requests from a number of processes, in which case only the one process (namely, the process 

9 associated with spin daemon 17) will be performing these operations instead of a plurality of 
tl processes. Accordingly, spin daemon 17 would not waste any more processor time than would 

10 having a single process, such as process 12(n f )(m') described above, perform the spin-wait 
U operations, and it can result in less waste if a number of such processes are waiting for information 

* ll from other processes. For example, continuing with the above example, if process 12(n")(m") is 

1+4 waiting for information from process 1 2(n ! )(m'), and process 12(n"')(m ! ") is waiting for information 

13 from process 12(n")(m"), then three processes, namely, processes ^(n'Xm'), 12(n M )(m") and 

ffi 1 2(n"')(m m ) would, in the absence of the spin daemon 1 7, be performing spin- wait operations waiting 

ti for the required information during the time slots in which they are executed. With the use of the 

11 spin daemon 17, only one process, namely, that associated with the spin daemon 17 itself, will be 

19 performing these operations, and the processes ^(n'Xm'), 12(n")(m") and 12(n m )(m'") will not be 

20 scheduled until the information that they require has been provided to them. 

2 1 In addition, the process for the spin daemon 1 7 can be executed at a lower priority level, that 
. 22 is, less often, than the processes 12(n)(m) of the programs ll(n), and, as long as the number of 

23 processes 1 2(n)(m) which have not de-scheduled themselves and therefore can be executed is greater 

' 24 than or equal to the number of processors comprising the computer 1 0, the computer can still make 

25 progress in connection with processing of those programs. If the number of processes 12(n)(m) 

26 which have de-scheduled themselves, and which will not be executed, increases to a point at which 

27 the number which can be executed falls below the number of processors, both the processes 1 2(n)(m) 
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1 that are still executing and the spin daemon 17 will be accommodated by the processors, in which 

2 case the spin daemon 17 will be executed more often. 

3 In one embodiment, in which the operating system 14 is in the form of Unix or a Unix-like 

4 operating system, the processes 12(n)(m) and spin daemon 17 communicate over respective sockets. 

5 In that embodiment, each process 12(n)(m) initially requests the operating system 14 to establish a 

6 socket between it (that is, the process 12(n)(m)) and the spin daemon 17. After the operating system 

7 has established the socket, the process 12(n)(m) performs a registration procedure with the spin 

8 daemon 17, in which it (that is, the process 12(n)(m)) provides the spin daemon 17 with its 

9 identification and information such as the address of its flag 1 6(n)(m) in the common memory 13, 
iS and the spin daemon 17 returns an identifier or handle that the process 12(n)(m) can use in flag 
tl monitor requests to the spin daemon 17. Since sockets are used as the communication mechanisms 
13 between the processes 1 2(n)(m) and spin daemon 1 7, when the spin daemon 1 7 has no outstanding 

* li flag monitor requests from the processes 12(n)(m), it (that is, the spin daemon 1 7) can de-schedule 
ft itself so that the operating system 1 4 will not enable it to be executed, and, when a process 1 2(n)(m) 
9 issues a flag monitor request over its respective socket to the spin daemon 1 7, the operating system 
i§ 1 4 will enable the spin daemon 1 7 to be executed, at which point the spin daemon 1 7 can enable the 
H operating system 14 to re-schedule it for execution. Similarly, after a process 12(n)(m) has de- 
ll scheduled itself as described above, when the spin daemon 17 determines that the condition of its 

1 9 flag 1 6(n)(m) has changed, it (that is, the spin daemon) will transmit a request over the socket, which 

20 will enable the operating system 1 4 to resume execution of the process 1 2(n)(m), which at that point 

21 will enable itself to be re-scheduled as described above. 

. 22 In that same embodiment, the spin daemon 17 also provides, for each flag monitor request 

23 which it loads in the spin list 18, a time stamp that identifies the time at which the flag monitor 

24 request was received. If the time stamps associated with the flag monitor requests in the spin list 1 8 

25 indicate that all of them (that is, the flag monitor requests) are relatively old, the spin daemon 1 7 can 

26 determine that it will likely be some time before any of the flags 1 6(n)(m) which it is monitoring is 

27 likely to be set. In that case, it can de-schedule itself and establish a timer set to expire after a 
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1 selected time interval After the timer expires, the spin daemon 1 7 will resume execution determine 

2 whether any of the flags 1 6(n)(m) which it is monitoring have been set, and, if so enable itself to be 

3 re-scheduled and notify the process 12(n)(m) associated with the flag(s) 1 6(n)(m) which have been 

4 set. On the other hand, if the spin daemon 17 determines that none of the flags 16(n)(m) have been 

5 set, it can establish another timer and repeat the above-described operation. 

6 A process 12(n)(m) can generate a flag monitor request, transmit it to the spin daemon 17 

7 and de-schedule itself immediately after performing one or only a few spin-wait loops. 

8 Alternatively, the process 12(n)(m) may delay performing these operations for some time. In one 

9 embodiment, a process 12(n)(m) will generally delay for approximately the time required for the 
jl process 1 2(n)(m) to de-schedule itself and reschedule itself, which in one embodiment is on the order 
lij of twice the time required for a context switch at the end of a time slot. As a further alternative, a 
U process 1 2(n)(m) may, after performing a selected number of spin-wait loops, give up the remaining 
il portion of its current time slot, and repeat that operation for a selected number of subsequent time 
Pf slots during which it is executed before generating the flag monitor request, transmit it to the spin 
tf daemon 17 and de-schedule itself. 

f| As described above, when the spin daemon 17 determines that a flag 16(n)(m) which it is 

ijjjjf monitoring has been set, it will transmit a message to the process 1 2(n)(m) associated therewith over 

1 8 the respective socket, which, in turn, enables the process 12(n)(m) to, in turn, enable itself to be re- 

19 scheduled. As an alternative, the spin daemon 17 itself can enable the process 12(n)(m) to be re- 

20 scheduled. In that case, the spin daemon will not need to transmit the message to the process 

21 1 2(n)(m), and the process 12(n)(m) will next be executed when the operating system 14 selects it 

22 from the task list 15 for execution. 

,23 As further described above, a process 12(n)(m) will perform a registration operation in 

24 connection with the spin daemon 17 prior to generating a flag monitor request for transmission to 

25 the spin daemon 1 7. A process 1 2(n)(m) may perform a registration operation at any point between 

26 the time the process 12(n)(m) is executed for the first time and the first time the process 12(n)(m) 
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1 is to transmit a flag monitor request to the spin daemon 17. If a process 1 2(n)(m) waits until the first 

2 time it is to transmit a flag monitor request to the spin daemon 17 to perform the registration 

3 operation, if the process 12(n)(m) never needs to make use of the spin daemon 17, it need not take 

4 the time to perform a registration operation. 

5 With this background, operations performed by a process 12(n)(m) and the spin daemon 1 7 

6 will be described in connection with the flow chart depicted in FIG. 2. With reference to FIG. 2, the 

7 process 12(n)(m) first initiates a registration operation with the spin daemon 1 7. In that operation, 

8 the process 12(n)(m) initially requests the operating system 14 to establish a socket between it (that 

9 is process 12(n)(m) and the spin daemon (step 100). After the operating system 14 provides a 
IS response to the process 12(n)(m) indicating that the socket has been established (step 101), the 
W process 1 2(n)(m) generates a registration request, including its identification and the location of its 
W flag 16(n)(m) in the shared memory 13, and transmits the registration request over the socket (step 

* lS 102). The spin daemon 17 receives the registration request from the socket (step 103), load the 

1# process identification and flag location information in a registration list 1 9 along with a handle (step 

1SS 104), and generate a registration response including the handle for transmission to the process 

lift 12(n)(m) over the socket (step 105). The process 12(n)(m), in turn, will receive the registration 

f if response (step 106) and store the handle for later use (step 107). 

1 8 After the process 1 2(n)(m) receives the handle from the spin daemon 1 7, if it later determines 

1 9 that it is to generate a flag monitor request for transmission to the spin daemon 1 7 (step 1 1 0), it will 

20 generate the flag monitor request, including the handle (step 111), transmit it (that is, the flag 

2 1 monitor request) to the spin daemon 1 7 over the socket (step 112) and de-schedule itself (step 113). 
- 22 The spin daemon 17, in turn, receives the flag monitor request (step 1 14), uses the handle in the 

23 request to identify the location of the flag 1 6(n)(m) to be monitored in the common memory 1 3 (step 

24 115), and loads an entry into its spin list 18 for the request, identifying the location of the flag 

25 1 6(n)(m) to be monitored (step 1 1 6). 
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1 After the spin daemon 1 7 has loaded the flag monitor request entry into its spin list 1 8 in step 

2 1 16, it (that is, spin daemon 17) will iteratively sequence through the flag monitor request entries 

3 in the spin list 18, to determine whether the condition of any of the flags identified therein has 

4 changed from the clear condition to the set condition (step 1 17). If, during processing operations 

5 in connection with step 1 1 7, the spin daemon 1 7 receives a registration request from a process (step 

6 1 1 8) it will sequence to step 1 03 to handle the request.. Similarly, if, during processing operations 

7 in connection with step 1 1 7, the spin daemon 1 7 receives a flag monitor request from a process (step 

8 119), it will return to step 1 10 to handle the flag monitor request. On the other hand, if, during 

9 processing operations in connection with step 1 1 7, the spin daemon 1 7 determines that the condition 
10^ of one of the flags ^(n'Xm 1 ) has changed from the clear condition to the set condition (step 120), 
1 Ifi it (that is, the spin daemon 1 7) will generate a notification for transmission to the process 1 2(n')(m ! ) 
12=1 associated with the flag (step 121) and transmit it (that is, the notification) over the socket to the 
13t! process 12(n')(m') (step 122). Thereafter, the spin daemon 17 can return to step 117 to continue 
14? ! monitoring. 

lfU After the process 12(n')(m r ) receives the notification transmitted in step 122 (step 123), it 

16*1 (that is, the process 12(n r )(m f ), will enable itself to be re-scheduled (step 124) by requesting the 

175 operating system 14 to load information into the task list 15 which it (that is, the operating system 

lSp 14) uses to select processes for execution. Thereafter, at some point in the operating system 14 will 

19 select the process 12(n')(m ! ), among other processes which may be listed on the task list, for 

20 execution. 

21 The invention provides a number of advantages. In particular, the invention provides a 

22 computer that efficiently controls scheduling of execution of processes or threads comprising one 

23 or more parallel programs in a compute having a plurality of processors, such as a computer 

24 constructed according to a symmetric multi-processor architecture, or a cluster of such computers, 

25 when the processes or threads may be waiting for information from other processes or threads. 
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1 It will be appreciated that a number of modifications may be made to the computer 10 as 

2 described above. For example, although the invention has been described in connection with a single 

3 computer, in the form of a symmetric multi-processor, it will be appreciated that the invention may 

4 be used in connection with a plurality of such computers interconnected by a network or other 

5 communication medium, and particularly if the computers are connected so as to organize their 

6 common memories as remote shared memories. In that case, each of the computers can include a 

7 respective spin daemon 17 which handles flag monitor requests in connection with processes and 

8 threads executing on the respective computer. In accordance with the remote shared memory 

9 architecture, the individual common memories of the respective computers are deemed to form a 
\M\ single common memory across all computers, and, when a process on one computer sends 
lfi information to a process on another computer, a network interface on the one computer will intercept 
1® the information and transmit it over the network to the other computer. A network interface on the 
lj: other computer will then load the information into the portion of the common memory associated 
t% with the destination process. Accordingly, a process on the one computer can enable information 
15 requested by a process on another and enable the process's flag 1 6(n)(m) by performing operations 
IM similar to those described above in connection with FIG, 1, and the network interfaces on the two 
l5 computers will enable the information to be transferred to the other computer and the flag to be set. 
iS The spin daemon 17 on the other computer can note that the flag has been set and perform the 

19 operations described above to enable the process to be re-scheduled. 

20 Furthermore, although the invention has been described with each process 1 2(n)(m) having 

2 1 one flag 1 6(n)(m), it will be appreciated that processes 1 2(n)(m) may have a plurality of flags whose 

22 condition can be monitored by the spin daemon 17. In that case, the processes 12(n)(m) can register 

23 each flag individually and receive a handle therefor from the spin daemon 17 for use as described 
s 24 above. Alternatively, if a process's flags are in a memory segment, and the segment only contains 

25 such flags, the process 12(n)(m) can register the memory segment and receive a handle for the 

26 segment. In that case, when the process 12(n)(m) issues a flag monitor request to the spin daemon 

27 17, the request is actually to monitor the entire segment, and, if a change occurs anywhere in the 
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1 segment, the spin daemon 17 will enable the process 12(n)(m) to be re- scheduled, either by directly 

2 requesting the operating system 14 or by sending a message to the process 12(n)(m), which, in turn, 

3 can enable itself to be re-scheduled. 

4 In addition, as noted above, in one embodiment, the operating system 14 is a Unix-like 

5 operating system. In that embodiment, since each flags 16(n)(m) may take a number of forms, 

6 including an integer, a short- or long-word, or a range of addresses, and the like, and a variety of 

7 mechanisms may be used in changing a condition of a flag, in that embodiment the spin daemon 1 7 

8 is provided with mechanisms which can detect changes in value of the integer, short- or long- word, 

9 or the like, from or to a predetermined value, to a predetermined value. 

1 (P Furthermore, although the invention has been described in connection with processes which 

1 © communicate using a message passing methodology, it will be appreciated that the invention can be 

1 J used in connection with processes which communicate using other methodologies. 

13h It will be appreciated that a system in accordance with the invention can be constructed in 

1© whole or in part from special purpose hardware or a general purpose computer system, or any 

lSj combination thereof, any portion of which may be controlled by a suitable program. Any program 

l ift: may in whole or in part comprise part of or be stored on the system in a conventional manner, or it 

IB may in whole or in part be provided in to the system over a network or other mechanism for 

1 8 transferring information in a conventional manner. In addition, it will be appreciated that the system 

1 9 may be operated and/or otherwise controlled by means of information provided by an operator using 

20 operator input elements (not shown) which may be connected directly to the system or which may 

21 transfer the information to the system over a network or other mechanism for transferring 

22 information in a conventional manner. 

23 The foregoing description has been limited to a specific embodiment of this invention. It will 

24 be apparent, however, that various variations and modifications may be made to the invention, with 

25 the attainment of some or all of the advantages of the invention. It is the object of the appended 
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1 claims to cover these and such other variations and modifications as come within the true spirit and 

2 scope of the invention. 

3 What is claimed as new and desired to be secured by Letters Patent of the United States is: 
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Claims 

1 1 . A system for controlling co-scheduling of processes in a computer comprising at least one process 

2 and a spin daemon, the process being configured to, when it is waiting for a flag to change condition, 

3 transmit a flag monitor request to the spin daemon and de-schedule itself, the spin daemon being 

4 configured to, after receiving a flag monitor request monitor the flag and, after the flag changes 

5 condition, enable the at least one process to be re-scheduled for execution by the computer. 

© 2. A system as defined in claim 1 in which said spin daemon is configured to monitor a plurality of 

Qj flags, each in response to a flag monitor request, the spin daemon maintaining a list identifying those 

Ti flags it is to monitor, the spin daemon being further configured to, when it receives a flag monitor 

# request, add an identification of a flag associated with the request to the list. 

;f : 3. A system as defined in claim 2 in which said flags are contained in a memory segment, the spin 

0 daemon being configured to enable the at least one process to be re-scheduled following a change 
;J of condition of any flag in said memory segment. 

1 4. A system as defined in claim 1 in which said at least one process is configured to register with 

2 said spin daemon, during registration the at least one process being configured to provide the spin 

3 daemon with an identifier for the memory segment, the spin daemon being configured to provide a 

4 handle, the at least one process being configured to use the handle in the flag monitor request. 
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1 5. A system as defined in claim 1 in which said at least one process and said spin daemon are 

2 configured to communicate over a socket. 

1 6. A method of controlling co-scheduling of processes in a computer comprising at least one process 

2 and a spin daemon, the method comprising the steps of: 

3 A. enabling the process to, when it is waiting for a flag to change condition, transmit a flag 

4 monitor request to the spin daemon and de-schedule itself, 

•3% B . enabling the spin daemon to, after receiving a flag monitor request monitor the flag and, after 

M the flag changes condition, enable the at least one process to be re-scheduled for execution 

■•5 by the computer. 

% 7. A method as defined in claim 6, the spin daemon being configured to monitor a plurality of flags, 

O 

:£ each in response to a flag monitor request, the spin daemon maintaining a list identifying those flags 

i4j it is to monitor, the method including the step of enabling the spin daemon being to, when it receives 

; fj a flag monitor request, add an identification of a flag associated with the request to the list. 

1 8. A method as defined in claim 7 in which said flags are contained in a memory segment, the 

2 method including the step of enabling the spin daemon to enable the at least one process to be re- 
. 3 scheduled following a change of condition of any flag in said memory segment. 



1 9. A method as defined in claim 6 further including the steps of 
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2 A enabling the at least one process to register with said spin daemon, during registration the 

3 at least one process being configured to provide the spin daemon with an identifier for the 

4 memory segment; and 

5 B. enabling the spin daemon to provide a handle for use by the at least one process in the flag 

6 monitor request. 

1 10. A method as defined in claim 6 further comprising the step of enabling the at least one process 

2 and said spin daemon communicate over a socket. 

Q 

ill 1 1 . A computer program product for use in connection with a computer to control co-scheduling of 

* J at least one process in the computer, the computer program product including a computer readable 

f medium having encoded thereon: 

i; A. a process module configured to enable the computer to, when the process is waiting for a flag 

% to change condition, transmit a flag monitor request to the spin daemon and de-schedule 

# itself, 

7 B. a spin daemon module configured to enable the computer to, after receiving a flag monitor 

8 request monitor the flag and, after the flag changes condition, enable the at least one process 

9 to be re-scheduled for execution by the computer. 

1 12. A computer program product as defined in claim 1 1 in which said spin daemon is configured to 

2 enable the computer to monitor a plurality of flags, each in response to a flag monitor request, the 

3 spin daemon enabling the computer to maintain a list identifying those flags it is to monitor, the spin 
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4 daemon being further configured to enable the computer to, when it receives a flag monitor request, 

5 add an identification of a flag associated with the request to the list. 

1 13. A computer program product as defined in claim 12 in which said flags are contained in a 

2 memory segment, the spin daemon being configured to enable the computer enable the at least one 

3 process to be re-scheduled following a change of condition of any flag in said memory segment. 

; i% 14. A cp as defined in claim 11 in which said at least one process is configured to enable the 

% computer to register with said spin daemon, during registration the at least one process being 

3 configured to enable the computer to provide the spin daemon with an identifier for the memory 

1 segment, the spin daemon being configured to enable the computer to provide a handle, the at least 

'% one process being configured to use the handle in the flag monitor request. 

% 1 5 . A computer program product as defined in claim 1 1 in which said at least one process and said 

# spin daemon are configured to enable the computer to communicate over a socket. 
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Abstract Of The Disclosure 
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2 A system is described for controlling co-scheduling of processes in a computer comprising 

3 at least one process and a spin daemon. The process, when it is waiting for a flag to change 

4 condition, transmits a flag monitor request to the spin daemon and enables itself to be de-scheduled. 

5 The spin daemon, after receiving a flag monitor request, monitors the flag and, after the flag changes 

6 condition, enables the process to be re-scheduled for execution by the computer. Since the spin 

7 daemon can monitor flags for a number of processes, the ones of the processes that are waiting will 

8 not need to be executed, allowing other processes that are not just waiting to be processed more 
11 often. 



100. PROCESS 12(n)(m) REQUESTS THE OPERATING 
SYSTEM 14 TO ESTABLISH A SOCKET BETWEEN IT AND 
THE SPIN DAEMON 



I 



101 . OPERATING SYSTEM 14 RESPONDS TO THE 
PROCESS 12(n)(m) WHEN SOCKET HAS BEEN 
ESTABLISHED 



] 
] 



102. PROCESS 12(n)(m) GENERATES A REGISTRATION 
REQUEST, INCLUDING ITS IDENTIFICATION AND THE 
LOCATION OF ITS FLAG 16(n)(m) IN THE SHARED 
MEMORY 13, AND TRANSMITS THE REGISTRATION 
REQUEST OVER THE SOCKET 



103. SPIN DAEMON 17 RECEIVES THE REGISTRATION 
REQUEST FROM THE SOCKET 



I 



104. SPIN DAEMON 17 LOADS THE PROCESS 
IDENTIFICATION AND FLAG LOCATION INFORMATION IN 
A REGISTRATION LIST 19 ALONG WITH A HANDLE 



J 



105. SPIN DAEMON 17 GENERATES A REGISTRATION 
RESPONSE INCLUDING THE HANDLE FOR TRANSMISSION 
TO THE PROCESS 12(n)(m) OVER THE SOCKET 



106. PROCESS 12(n)(m) RECEIVES THE REGISTRATION 
RESPONSE 



J 



107. PROCESS 12(n)(m) STORES THE HANDLE FOR LATER 
USE 



El. 



110. PROCESS 12(n)(m) DETERMINES THAT IT IS TO 
GENERATE A FLAG MONITOR REQUEST FOR 
TRANSMISSION TO THE SPIN DAEMON 17 



111. PROCESS 12(n)(m) GENERATES FLAG MONITOR 
REQUEST, INCLUDING THE HANDLE RECEIVED IN STEP 
107 



112. PROCESS 12(n)(m) TRANSMITS FLAG MONITOR 
REQUEST TO THE SPIN DAEMON 17 OVER THE SOCKET 



113. PROCESS 12(n)(m) DE-SCHEDULES ITSELF 



J 



114. SPIN DAEMON 17 RECEIVES THE FLAG MONITOR 
REQUEST 



115. SPIN DAEMON 17 USES THE HANDLE IN THE 
REQUEST TO IDENTIFY THE LOCATION OF THE FLAG 
16(n)(m) TO BE MONITORED IN THE COMMON MEMORY 13 



J 



116. SPIN DAEMON 17 LOADS AN ENTRY INTO ITS SPIN 
LIST 18 FOR THE REQUEST, IDENTIFYING THE LOCATION 
OF THE FLAG 16(n)(m) TO BE MONITORED 



) 



6 



FIG.2A 




FIG. 2B 



/fl7. SPIN DAEMON 17 ITERATIVELY SEQUENCES 
THROUGH THE FLAG MONITOR REQUEST ENTRIES IN 
THE SPIN LIST 18 TO DETERMINE WHETHER THE 
CONDITION OF ANY OF THE FLAGS IDENTIFIED THEREIN 
HAS CHANGED FROM THE CLEAR CONDITION TO THE 
SET CONDITION 



118. SPIN DAEMON 17 DETERMINES WHETHER IT 
RECEIVED A REGISTRATION REQUEST FROM A PROCESS 



NO 



J- YES 



119. SPIN DAEMON 17 DETERMINES WHETHER IT 
RECEIVED A FLAG MONITOR REQUEST FROM A 
PROCESS 



NO 



J_YES 



4NO- 



120. SPIN DAEMON 17 DETERMINES THAT THE 
CONDITION OF ONE OF THE FLAGS lefn'Xm') HAS 
CHANGED FROM THE CLEAR CONDITION TO THE SET 
CONDITION 



YES 



121. SPIN DAEMON 17 GENERATES A NOTIFICATION FOR 
TRANSMISSION TO THE PROCESS 12(n')(m") ASSOCIATED 
WITH THE FLAG 



] 



122. SPIN DAEMON 17 TRANSMITS NOTIFICATION OVER 
THE SOCKET TO THE PROCESS 12(n , )(m') 



123. PROCESS 12(n')(m') RECEIVES THE NOTIFICATION 
TRANSMITTED IN STEP 122 



124. PROCESS ^(n'Mm') RE-SCHEDULES ITSELF 
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